Why

The previous shape (closed in governance-cloud#4) put modality config on a global org-level toggle. That coupled unrelated policies and was nonsensical for metadata-only rules (rate_limit, token_budget, kill_switch).

Each policy that semantically scans content should declare its own modality coverage. A prompt_injection rule might want ['text', 'image']; a separate sensitive_data_filter rule might want only ['text']. Per-policy granularity, single shared OCR pass per request, no hidden coupling.

This PR is the SDK groundwork for that. Cloud-side UI + enforce-orchestrator wiring lands in a follow-up that imports the new types and helpers.

API surface

// PolicyRule
interface PolicyRule {
  // ...existing fields
  scanModalities?: Modality[]; // optional; only meaningful for content-scanning conditions
}

// EnforcementContext
interface EnforcementContext {
  // ...existing fields
  textByModality?: Partial<Record<Modality, string>>; // host populates
}

// New exports from governance-sdk/scan/multi-modal
export const CONDITIONS_SUPPORTING_MODALITIES: ReadonlySet<string>;
export function conditionSupportsModalities(conditionType: string): boolean;

// New export from governance-sdk (top-level via policy.ts)
export function getScanText(
  ctx: EnforcementContext,
  rule?: PolicyRule,
): string[] | null;  // null = "use the legacy fallback"

What changes in the engine

• ConditionEvaluator widened to (ctx, params, rule?) => boolean. Structurally backward-compatible — existing (ctx, params) => boolean implementations satisfy the wider signature unchanged.
• evaluateCondition, evaluate, evaluateStage thread the rule through so evaluators can read rule.scanModalities.
• Six content-scanning evaluators updated to consult getScanText(ctx, rule) and fall back to their original behaviour when it returns null.
• Combinators (any_of, all_of, not) synthesise a per-child rule view: preserves parent's scanModalities, rebinds condition to the nested type. So any_of over injection_guard + blocklist with scanModalities: ['image'] correctly scopes both sub-checks to image text.

Conditions that get scanModalities

Everything else — tool_blocked, cost_budget, concurrent_limit, time_window, agent_level, network_allowlist, scope_boundary, require_signed_identity, require_signed_action, length checks, combinators themselves — operates on metadata. The registry rejects scanModalities on those at the helper level so they remain inert when set.

Backward compatibility

• Rules without scanModalities see exactly the same content as before. getScanText returns null, the evaluators fall back to extractStrings(ctx.input) / ctx.outputText / etc. — verified by the existing 1,399 tests passing unchanged.
• ConditionEvaluator's third parameter is optional. Custom evaluators registered by callers keep working.
• No changes to public type exports for existing fields.

What's NOT in this PR (follow-ups)

1. Cloud policy editor UI — per-rule modality selector that only renders on rule types whose condition supports modalities. Imports conditionSupportsModalities from this PR.
2. Cloud enforce orchestrator wiring — single scanMultiModal() call per request for the union of modalities across active rules, populates ctx.textByModality, then invokes enforce(). Plus a default extractor (Groq vision is the easiest reuse — the client's already wired for Tier-3).
3. Cloud PATCH /api/v1/saved-policies validator — rejects scanModalities on unsupported condition types at write time. Uses the exported helper.

Tests

• New src/per-rule-modalities.test.ts (14 tests):
  • Registry contents (six in, all metadata-only condition types out)
  • getScanText null paths (no rule / unsupported condition / unset modalities) and non-null paths (per-modality slices, missing-modality skip)
  • Per-rule dispatch: text-only rule does NOT match on image content and vice versa
  • Multi-rule independence (two rules scoped to different modalities)
  • scanModalities ignored on non-content-scanning rule (cost_budget proxy)
  • Combinator propagation (any_of with parent scanModalities=['image'] correctly catches a hit only when the target text is in the image modality)
• 1,413 / 0 tests total (was 1,399 / 0 before this PR).

Test plan

• npm run build clean
• npm test 1,413 / 0
• Reviewer skims src/policy.ts (PolicyRule, EnforcementContext, ConditionEvaluator, getScanText, evaluator-threading)
• Reviewer skims src/conditions/builtins.ts (six evaluator wrappers + combinator child-rule synthesis)
• Reviewer confirms the registry list in src/scan/multi-modal.ts is complete (no false negatives, no false positives)

🤖 Generated with Claude Code